AI需求分析实战：用提示词把想法变成结构化需求
你会学到什么
从本节开始，课程进入项目实战阶段——把前面认识过的 AI 工具、Claude Code 环境配置这些"零部件"，串成一条完整的开发工作流。需求分析不是"随便聊聊天让AI帮我想想"。它有两套明确的产出物：产品经理视角的需求文档和开发者视角的技术方案。本节讲清楚这两套产出分别是什么、传统做法怎么做、AI时代怎么做快10倍，以及用什么AI工具配合完成。
先摆正视角：产品的事不只是产品经理的事
很多开发者对"参与需求"的理解，是找产品经理要一份 PRD 文档——这远远不够。产品经理从全局角度思考的事情：功能清单、功能开发的优先级、和用户的沟通、最后的验收标准，每一件都和开发者强关联。落到开发者视角，它们分别对应：
- 技术方案的落地：功能清单里每一项怎么实现
- 架构设计：优先级决定什么先做、做到什么程度
- API 设计：验收标准最终落在接口行为上
- 开发排期与分批计划：优先级排序的工程化表达
在 AI 时代，一个人要同时扮演产品和技术两个角色，这种大局观不是可选项，而是前置条件——你得先知道完整流程长什么样，才知道该让 AI 在哪个环节介入。本节的目标就是给你这张全景图：来了一个项目，流程是什么、每个环节 AI 怎么参与、关联的文件有哪些。
需求分析到底要产出什么？
很多人把"需求分析"理解成"列个功能清单"，这远远不够。一个完整的需求分析要同时回答两个问题：
产品经理要回答：我们做什么、为什么做、做到什么程度？
产出物：
| 文档 | 内容 | 给谁看 |
|---|---|---|
| 产品定位文档 | 目标用户、核心问题、差异化价值 | 团队所有人 |
| 功能清单与优先级 | 做什么、不做什么、先做什么 | 开发者 |
| 用户故事 | 典型使用场景和验收标准 | 开发者、测试 |
开发者要回答：怎么做、用什么做、什么时候做完？
产出物：
| 文档 | 内容 | 给谁看 |
|---|---|---|
| 技术方案 | 架构设计、技术选型、目录结构 | 开发团队 |
| API设计文档 | 组件接口、命名规范、类型定义 | 开发者 |
| 开发排期 | 按批次排列的任务和时间线 | 项目管理 |
传统做法下，产品经理写PRD、开发者写技术方案，两个人可能来回讨论一周。AI时代，一个人就能完成这两套产出——前提是你会用工具。
传统做法 vs AI做法
传统做法（以Vue3组件库为例）
- 产品经理调研竞品、写PRD（3-5天，急项目压缩到1-2天）
- 技术评审：开发评估工时、讨论可行性和排期（1-2天）
- 开发者写技术方案、定义API（2-3天）
- 反复修改、对齐（2-3天）
- 开发、测试、提测、部署上线，以及资源的划分
总计：1-2周才能把一件具体的事情落地。
AI做法
有了 AI 之后，上面所有环节都可以让 AI 参与——区别只在于每个环节用什么工具、走什么流程：
- 用Claude Code初始化项目上下文（10分钟）
- 用结构化提示词生成产品定位和功能清单（30分钟）
- 用AI迭代生成API设计文档（1小时）
- 让AI扮演用户验证API合理性（30分钟）
- 人工审核和调整（1-2小时）
总计：半天
省下来的不是思考时间——你仍然要自己做决策——省下来的是文档编写和信息收集的时间。过去说"一个人当几个人用"是夸张的说法，在 AI 时代，这是真的可以做到的。
工具配合：用什么做什么
不同的产出物用不同的AI工具，不是所有事情都靠一个提示词搞定：
产品经理视角的工具链
| 产出物 | 推荐工具 | 为什么 |
|---|---|---|
| 市场调研、竞品信息 | 网页搜索（Claude Code内置或DuckDuckGo） | 需要最新数据，AI训练数据可能过时 |
| 产品定位、用户故事 | Claude Code 对话 | 需要多轮迭代，Claude Code保持上下文 |
| 功能优先级排序 | Claude Code + 结构化提示词 | 需要结合约束条件做权衡 |
| PRD文档 | Claude Code 直接生成 | 格式化输出是AI的强项 |
开发者视角的工具链
| 产出物 | 推荐工具 | 为什么 |
|---|---|---|
| 技术选型 | Context7 MCP 查最新文档 | 框架API可能变了，需要查最新版本文档 |
| API设计 | Claude Code 对话 + TypeScript | AI生成TS接口定义，直接可落地 |
| 架构设计 | Claude Code + CLAUDE.md | 把架构决策写入CLAUDE.md，后续开发自动遵守 |
| 开发排期 | Claude Code 对话 | 根据组件复杂度自动估算 |
AI需求分析的两个关键能力：搜索与记忆
上面工具链里有一个隐藏的前提条件——信息从哪来？上下文怎么保持？
为什么需要搜索能力？
产品经理做需求分析，至少要搜索这些信息：
- 竞品数据：Element Plus 多少组件？Naive UI 的 API 风格是什么？这些信息需要实时搜索，AI 训练数据可能过时
- 技术趋势：2026 年 CSS-in-JS 还流行吗？Web Components 生态成熟了吗？技术趋势一直在变，需要搜索最新文章
- 用户反馈：GitHub Issues、社区讨论中的真实痛点
Claude Code 内置了 WebSearch，但依赖订阅、国内网络不稳定、有速率限制、结果不可控。你可能会想：订阅的 Coding Plan 都自带搜索（Kimi、MiniMax、Gemini 都有），够不够用？它们都有频次或次数上限——以 Gemini CLI 为例，免费层按模型请求数计，Google 账号登录约 1000 次/天、API Key 约 250 次/天，订阅 AI Pro/Ultra 后更高（讲师实测订阅档搜索上限约 4000 次/天、且包含图片解析；配额随套餐动态调整，以官方文档为准）。而且这些内置搜索不能连续爬取网页，连续调用会被限流。
自建本地搜索系统是更好的方案——下一节我们会配置 /local-search skill，让 AI 自主完成"搜索 → 爬取 → 整理 → 输出报告"的全流程。为什么强调自己搭一遍？一方面是学会把搜索、爬取、整理这些能力揉在一起，在 AI 时代给自己打造趁手的兵器；另一方面，搭过之后再去看社区现成方案，一对比就知道好坏了——后面课程也会推荐社区方案。
为什么需要记忆能力？
需求分析不是一次性完成的，它是一个持续迭代的过程：
第1天：产品定位讨论 → 产出定位结论
第2天：功能清单讨论 → 基于定位继续
第3天：API设计 → 基于功能清单继续
...
text
问题来了：每次打开 Claude Code 开始新对话，AI 之前的讨论全忘了。你得重新说明项目背景、已确定的决策、技术栈约束。
CLAUDE.md 能解决部分问题，但它需要手动维护，而且只能记录最终的决策结果，无法记录"为什么做这个决策"的思考过程。
claude-mem 插件解决的就是这个问题——它自动记录每次对话的关键决策、Bug 修复、技术发现，下次新对话时自动注入上下文。后面的章节会详细配置。
搜索 + 记忆的协作模式
用户提出需求问题
↓
claude-mem 自动注入：上次讨论了什么、做了哪些决策
↓
local-search 搜索：竞品数据、技术趋势、用户反馈
↓
Claude Code 综合分析 → 产出需求文档
↓
claude-mem 自动记录：这次讨论的关键决策
text
这就是为什么本节重点讲这两个工具——搜索解决信息获取，记忆解决上下文保持。它们配合 CLAUDE.md 和结构化提示词，构成 AI 需求分析的完整工具链。
配置指南：
/local-search的完整配置见下一节02-本地化搜索与分析引擎&skill技能配置，claude-mem的安装配置见03-claude-mem记忆系统：跨会话持久化上下文。
实战：从零开始做需求分析
以下是一个完整的需求分析过程，产品经理视角和开发者视角交替进行。
第一步：建立项目上下文（10分钟）
做什么： 创建CLAUDE.md，让AI"理解"你的项目。
为什么先做这个： 没有CLAUDE.md，每次对话都要重复说明你的技术栈和约束。有了它，AI自动知道你的项目背景。
怎么做：
在项目根目录创建 CLAUDE.md，先写最基本的：
# Vue UI - 轻量级Vue3组件库
## 项目目标
一个轻量级、TypeScript原生的Vue3 UI组件库。
比Element Plus更轻，比Shadcn-Vue更完整，比Naive UI更简单。
## 技术栈
- Vue 3.5+ (Composition API + <script setup>)
- TypeScript 5 (strict mode)
- Vite 6 (库模式构建)
- pnpm workspace (monorepo)
- CSS变量做主题定制（不用CSS-in-JS）
## 目标用户
- 个人开发者和小团队的中后台项目
- 需要快速搭建UI，不想花时间配置主题
- 重视TypeScript类型推导
## 约束条件
- 一个人开发，2个月业余时间
- 核心包gzip后不超过50KB
- MVP阶段控制在15-20个组件
markdown
这一步是第3章01节学过的CLAUDE.md，现在用在实战中。 写完这个文件后，Claude Code后续的所有对话都会自动读取这些上下文。
第二步：产品定位——我们在做什么（30分钟）
角色：产品经理
有了CLAUDE.md，开始用对话梳理产品定位。这里的关键不是提示词多花哨，而是你自己的思考要清晰，AI帮你结构化表达。
基于CLAUDE.md中的项目信息，请帮我完成以下产品定位分析：
1. 目标用户画像：列出3类典型用户，每类包含
- 他们现在用什么库
- 他们对现有库最大的不满是什么
- 他们愿意为了什么特点切换到新库
2. 核心差异化：对比 Element Plus（全而重）和 Shadcn-Vue（轻而少），
我们的库在"功能覆盖"和"轻量程度"之间应该选什么位置？
3. 不做什么：列出我们明确不做的功能，附理由
输出格式：结构化markdown，每部分有明确结论
text
注意这个提示词用到了第4章学的约束条件技巧——给了具体竞品名称做参考锚点，而不是让AI泛泛而谈。
输出示例（你需要自己审核和修改的部分）：
产品定位结论（这个需要你自己决策，AI只是帮你梳理）：
- 位置：Element Plus和Shadcn-Vue之间——组件数比Shadcn多，但比Element Plus精简
- 核心卖点：TypeScript类型推导 + CSS变量主题 + 50KB核心包
- 明确不做：CSS-in-JS、SSR特殊处理、国际化内置、Table组件（MVP阶段）
"明确不做什么"是这一步最容易被忽略、也最值钱的部分，技术和范围两个维度都要说死。参考讲课时的实际例子：技术红线——后端不用 Node.js 也不用 Java，而是用 Python，因为这个产品要对接非常多的模型服务；范围红线——不要给我设计商城，系统里已经有商城了，只做对接；支付也不要重新实现，只考虑接入。约束写得越具体，AI 后续给出的方案就越不会跑偏。
第三步：功能清单与优先级（30分钟）
角色：产品经理 + 开发者共同参与
产品经理说"做什么"，开发者说"能做多少"。
我需要为这个Vue3组件库制定MVP功能清单。
约束条件：
- 一个人开发，2个月业余时间（实际可用约200小时）
- MVP需要覆盖：表单场景、反馈场景、基础交互
- 每个组件的Props不超过8个
请帮我：
1. 列出15-20个组件的建议清单，按以下分类：
- 基础控件（Button、Input、Tag等）
- 表单相关（Select、Checkbox、Form等）
- 反馈组件（Modal、Message、Tooltip等）
- 布局组件（如果需要的话）
2. 对每个组件标注：
- 优先级：P0（必须有）/ P1（应该有）/ P2（可以有）
- 开发复杂度：低（<4小时）/ 中（4-8小时）/ 高（>8小时）
- 依赖关系：是否依赖其他组件
3. 给出开发分批建议：
- 第一批：开发成本低 + 展示效果好的组件
- 第二批：高频使用的中等复杂度组件
- 第三批：复杂但必要的组件
输出：markdown表格
text
这个提示词同时给出了时间约束（200小时）、范围约束（15-20个组件）、设计约束（Props不超过8个），AI给出的方案才能直接落地。
这里开发者要做的判断： AI给的开发时间估算不一定准。Select组件AI可能说"中等复杂度4-8小时"，但如果你没做过虚拟滚动，实际可能要2天。**根据自己的经验调整AI给出的估算。**优先级适合"人工 + AI"共同定义，复杂度交给 AI 估算后再由开发者（或与团队开发的伙伴讨论）修正。清单和分批确定后，配套的甘特图、流程图也直接交给 AI 画——Mermaid 一句话出图，第6章会展开。
第四步：API设计规范（1小时）
角色：开发者主导
功能清单确定后，开发者的核心产出是API设计。这一步不适合纯用对话——需要产出TypeScript类型定义，Claude Code可以帮你生成。
先定规范，再写具体组件API。命名规则、文件组织这类约定，团队内部有现成文档就直接沿用；没有的话采用业界成熟规范——接口用 OpenAPI 3.x 描述，配 Swagger UI 或 ReDoc 渲染成文档，这些交给模型生成都已经非常容易：
请为我的Vue3组件库制定API设计规范，要求：
1. Props命名规范
- 和HTML原生属性保持一致的原则（举3个例子说明）
- 和Vue3惯例一致的原则（举3个例子说明）
- Boolean prop的默认值约定
2. Events规范
- v-model相关事件的命名
- 自定义事件的命名
- 原生事件是否透传
3. Slots规范
- 默认slot的使用约定
- 具名slot的命名约定
4. CSS变量规范
- 变量命名格式
- 哪些属性必须有变量
参考 Element Plus 和 Naive UI 的API设计，指出它们的优点和缺点，
然后给出我们的规范。规范要具体到"遇到XX情况应该用XX命名"的程度。
text
用Context7查最新API： 如果不确定Vue 3.5的某个特性怎么用，不要猜：
（通过Context7 MCP查询）
查询Vue 3.5中 defineModel 的最新用法，
我需要知道它是否已经稳定，以及和 props + emit 的写法有什么区别。
text
规范定好后，给一个组件生成完整API：
基于上面制定的API规范，为 Button 组件生成：
1. TypeScript interface（所有Props的类型定义）
2. defineEmits 的类型定义
3. defineSlots 的类型定义
4. CSS变量列表
5. 3个使用示例（基础、带图标、loading状态）
要求：
- Props不超过8个
- 不做 icon prop（用 slot 配合 Iconify）
- type 只支持 4 种：primary / default / dashed / text
text
第五步：让AI扮演用户验证（30分钟）
角色：QA/用户
API写出来不代表好用。让AI扮演不同水平的开发者来验证：
请扮演两个不同水平的开发者，分别尝试使用下面的Button组件API：
【新手开发者】只写过基本Vue，没用过组件库：
- 写一个带确认文字的提交按钮
- 写一个禁用状态和加载状态切换的按钮
【有经验开发者】用过Element Plus：
- 写一个按钮组（3个按钮：保存、取消、删除）
- 用CSS变量改按钮颜色
- 结合Form组件思考Button的 htmlType 怎么用最自然
遇到任何需要查文档才能理解的地方，就标记出来——这些是需要改进的设计。
text
开发者要关注的问题： AI标记出的"需要查文档"的地方，就是你的API设计不够直觉的地方。要么改名，要么提供更好的默认值。
这一步同时是一次早期的 MVP 验证：一方面验证整个流程是否跑得通、功能能不能真正落地，另一方面把前面的产品定位、功能清单、API 设计各环节串起来做一次总检验。
第六步：输出最终文档
验证完毕后，把所有产出整合成两份文档：
产品需求文档（给团队看的）：
请基于我们前面的所有讨论，生成一份组件库需求文档，包含：
1. 产品定位（2-3句话）
2. 目标用户画像（3类）
3. 组件清单表格（名称/分类/优先级/复杂度/依赖）
4. 开发分批计划
5. 明确不做的事情（附理由）
6. 成功标准（怎么算MVP完成了）
text
技术方案文档（给自己/开发者看的）：
请基于我们前面的讨论，生成技术方案文档，包含：
1. 技术栈确认（每个技术的版本和用途）
2. API设计规范摘要（Props/Events/Slots/CSS变量）
3. 项目目录结构（monorepo布局）
4. 构建方案（Vite库模式配置要点）
5. 关键技术决策及理由（为什么选CSS变量而不是CSS-in-JS等）
text
另外，PRD 不必等到用户验证环节才产生——项目一开始就可以让 AI 出一版初版，随讨论推进持续细化，人工审核后升级为详细需求文档；技术方案同理。文档是贯穿全程、持续迭代的产物，不是最后一刻的一次性交付。
这两份文档生成后，你必须人工审核。AI生成的内容80%是对的，但20%可能需要根据你的实际情况调整——特别是开发时间估算和优先级判断。
一个完整的提示词工作流总结
整个需求分析过程的提示词不是一次性的，而是链式的——每一轮的输出是下一轮的输入：
CLAUDE.md（上下文）
↓
产品定位对话 → 得出定位结论
↓
功能清单对话 → 得出组件列表
↓
API规范对话 → 得出命名约定
↓
具体组件API对话 → 得出TS接口定义
↓
用户验证对话 → 发现API问题 → 回到上一步修正
↓
生成需求文档 + 技术方案
text
这个流程和第4章学的**提示链（Prompt Chain）**是同一个模式——把大任务拆成小步骤，每步输出结构化结果，下一步基于上一步继续。
完整工具链全景图
把本章所有工具整合到一起：
CLAUDE.md（项目上下文，持续更新）
│
├── 对话分析 ──→ Claude Code（定位/清单/规范/API设计）
├── 信息搜索 ──→ /local-search（竞品数据/最新技术） ← 下一节配置
├── 技术查询 ──→ Context7（Vue/Vite最新文档）
├── 跨会话记忆 ──→ claude-mem（自动记录决策/发现） ← 下一节配置
│
├── 文档输出 ──→ Claude Code 生成 PRD + 技术方案
├── 图表输出 ──→ AI生成Mermaid → 渲染成图
└── PPT输出 ──→ AI生成演示文稿
text
注意：这些工具是辅助，不是替代。产品定位、功能优先级、技术选型这些关键决策必须你自己做。AI帮你把决策变成文档、图表、PPT，速度快10倍。
开发者在需求分析阶段容易犯的错
| 错误 | 正确做法 |
|---|---|
| 跳过产品定位直接写代码 | 先确定"给谁用、解决什么问题" |
| 想做一个"完整的"组件库 | MVP先做15-20个高频组件 |
| API设计照抄Element Plus | 学习优点但按自己的规范重新设计 |
| 不验证API就直接开发 | 用AI扮演用户验证，发现问题成本最低 |
| 不写CLAUDE.md就开工 | 先让AI理解项目上下文，后续所有对话都受益 |
| 需求分析花太多时间 | 控制在半天以内，AI加速文档编写 |
本节要点
- 需求分析有两套产出：产品经理视角（定位、功能清单、优先级）+ 开发者视角（技术方案、API设计、架构决策）——开发者也要有产品大局观，来了项目心中要有全景图：流程是什么、AI 在哪些环节起作用、关联的文件有哪些
- 传统做法1-2周，AI做法半天——省的是文档编写和信息收集，不是思考决策
- 工具配合：CLAUDE.md做上下文、网页搜索做调研、Context7查最新文档、Claude Code做迭代对话
- 搜索能力是AI需求分析的信息基础——自建 local-search 比内置搜索更可控
- 记忆能力是跨会话持续迭代的保障——claude-mem 自动记录决策，无需手动维护
- 提示词是链式的：定位→清单→规范→API→验证→文档，每步输出结构化结果
- AI生成的内容必须人工审核——特别是时间估算和优先级判断
下一节我们配置 /local-search 本地化搜索系统，让 AI 拥有自主搜索和分析的能力。
↑